Add read_to_end implementation to &[u8]'s Read impl #45083
Conversation
|
This looks good to me. Only a super minor curiosity, does it matter to us where the slice's pointer is when read_to_end returns? The remaining slice here points into a static |
|
I was briefly wondering the same thing and then I somehow got distracted and forgot. I guess it makes sense to set |
|
I don't think anyone would run into issues in practice with the current implementation, but switching to |
The default impl for read_to_end does a bunch of bookkeeping that isn't necessary for slices and is about 4 times slower on my machine.
fhartwig
force-pushed
the
slice-read-to-end
branch
from
dda3d07 to
d52acbe
Compare
|
I've changed the implementation. The method now sets |
|
Thanks! @bors r+ rollup |
|
📌 Commit d52acbe has been approved by |
bluss
added
the
S-waiting-on-bors
Add read_to_end implementation to &[u8]'s Read impl
The default impl for read_to_end does a bunch of bookkeeping
that isn't necessary for slices and is about 4 times slower
on my machine.
The following benchmark takes about 30 ns before this change and about 7 ns after:
```
#[bench]
fn bench_read_std(b: &mut Bencher) {
let data = vec![0u8; 100];
let mut v = Vec::with_capacity(200);
b.iter(|| {
let mut s = data.as_slice();
v.clear();
s.read_to_end(&mut v).unwrap();
});
}
```
This solves the easy part of rust-lang#44819 (I think extending this to `Take<&[u8]> `would require specialization)
The default impl for read_to_end does a bunch of bookkeeping
that isn't necessary for slices and is about 4 times slower
on my machine.
The following benchmark takes about 30 ns before this change and about 7 ns after:
This solves the easy part of #44819 (I think extending this to
Take<&[u8]>would require specialization)